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NASA’s Morpheus Project has developed and tested a prototype planetary lander 
capable of vertical takeoff and landing that is designed to serve as a testbed for advanced 
spacecraft technologies. The lander vehicle, propelled by a Liquid Oxygen (LOX)/Methane 
engine and sized to carry a 500kg payload to the lunar surface, provides a platform for 
bringing technologies from the laboratory into an integrated flight system at relatively low 
cost. In 2012, Morpheus began integrating the Autonomous Landing and Hazard Avoidance 
Technology (ALHAT) sensors and software onto the vehicle in order to demonstrate safe, 
autonomous landing and hazard avoidance. From the beginning, one of goals for the 
Morpheus Project was to streamline agency processes and practices. The Morpheus project 
accepted a challenge to tailor the traditional NASA systems engineering approach in a way 
that would be appropriate for a lower cost, rapid prototype engineering effort, but retain the 
essence of the guiding principles. This paper describes the tailored project life cycle and 
systems engineering approach for the Morpheus project, including the processes, tools, and 
amount of rigor employed over the project’s multiple lifecycles since the project began in 
fiscal year (FY) 2011. 
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I. Introduction 

Bom out of a technology demonstration mission concept called Project M, the Morpheus Project began in 
earnest in June of 2010. Its primary intent has been as a lander technology development activity that could 
eventually support human and robotic missions to any surface. The most visible aspect of the Morpheus Project is 
the autonomous, reusable, rocket-powered, terrestrial vertical test bed (VTB), which provides a platform to mature, 
refine, and demonstrate advanced technologies in a relevant flight environment. The Morpheus Project was 
challenged to provide this vehicle, the necessary ground support infrastructure, and operations capability to conduct 
flight tests using a lean development approach of a small team, rapid testing and turnaround, innovative partnerships 
and minimal resources. 

One of the primary technology components of the Morpheus Project is liquid oxygen (LOX) / liquid 
methane (LCH 4 ) propulsion. A LOX/LCH 4 propulsion system is clean-buming, non-toxic, cryogenic, and space- 
storable. For future space missions, oxygen and/or methane potentially could be produced in situ, depending on the 
planetary surface. Oxygen is compatible with on-board life support systems, and oxygen / methane systems are 
being studied for power generation as well. These attributes make LOX/LCH4 propulsion an attractive technology 
when the entire spacecraft system is considered. LOX and methane are also readily available on earth and relatively 
safe and easy to handle (being cryogenic but not toxic), allowing for frequent, low-cost ground testing. It is notable 
that Morpheus has demonstrated not just LOX/LCH4 propulsion for the main engine, but simultaneously with a set 
of four integrated LOX/LCH 4 roll control engines, and is the first flight vehicle to do so. 

When landing autonomously on any planetary or other surface, the vehicle must be able to identify a safe 
landing site that is free of large boulders, rocks, craters, or highly sloping surfaces. The second primary technology 
objective of the Morpheus project is to demonstrate and advance the TRL of precision landing and hazard avoidance 
capabilities developed by the ALHAT system. The ALHAT project has been developing an integrated Autonomous 
Guidance, Navigation, and Control (AGNC) hardware and software system capable of detecting and avoiding 


1 Morpheus Systems Engineering & Integration Manager, Mail Stop EA34 

2 Morpheus Project Manager, Mail Stop EA32, AIAA Senior Member 

1 

American Institute of Aeronautics and Astronautics 



surface hazards and autonomously guiding a manned or unmanned space vehicle to a safe touchdown within 90 
meters of a pre-designated planetary or asteroid site. A 100 m x 100 m hazard field has been built at the north end of 
the Shuttle Landing Facility to demonstrate landing on hazardous terrain. 

Other system elements besides the rocket-propelled flying vertical testbed vehicle and the ALHAT sensor 
suite include ground data systems, propellant loading, ground communications, an operational control center, an 
engineering team who also serves as the operations team, KSC test support, and safety, including range safety. 

Over four years, the project has spanned a total project life cycle from concept of operations through flight 
operations and sustaining engineering, with multiple prototypes and iterative design and development. In this time, 
the Morpheus project has built 2.75 nearly identical prototype vehicles, and conducted 60 flight tests: 12 static hot 
fires, 34 tether tests, and 14 free flights. The final five free flights at KSC successfully reached an altitude of 245 m 
and traveled 800 m downrange to a land safely in the hazard field with the ALHAT components integrated on board. 

While the overall system bears the look of a terrestrial test vehicle, the complexity cannot be understated. 
Utilizing low-cost components and in-house design, the project has demonstrated capabilities that many questioned 
were possible, including the operation of an integrated main engine and RCS system fed from a single LOX/LCH4 
source, the potential for self-correcting differential draining behavior from multiple prop tanks, and a dual-string 
parallel navigation scheme that allowed the vehicle to fly on the ALHAT navigation system, while remaining 
capable of down-moding to the alternate (fed by different GNC instruments) should a safe flight corridor be 
exceeded. All of this was accomplished on a fully autonomous vehicle that is reliably reusable and capable of flying 
to exacting performance standards (e.g. <0.1 deg attitude error) as required for ALHAT precision landing testing. 

Morpheus includes these major system elements: vehicle, payload (ALHAT), ground systems, and 
operations. 

The vehicle is further broken down into the following 10 subsystems: Avionics, Flight Dynamics, Flight 
Operation, Ground Systems, Power, Propulsion, Software, Structures, & Wiring. Vehicle integration and testing are 
led by the SE&I team. The vehicle is comprised of over 400 components, each tracked individually in the project’s 
master equipment list (MEL). An additional 125 sub-components are also tracked. The vehicle contains 
approximately 230 electrical interfaces (does not include interfaces between ALHAT payload components) and up 
to another 40 for developmental flight instrumentation (DFI) depending on vehicle configuration. There are also 
over 400 mechanical interfaces on the vehicle. In addition to the vehicle, there are also roughly 50 ground support 
equipment (GSE) items ranging in complexity from: the simple (e.g. prop transfer hose); medium (e.g. rechargeable 
vehicle battery cart); to highly complex (e.g. vehicle monitoring & data processing computers). 

II. Overview 

The Morpheus Project has wholly represented a lean development system engineering activity, taking 
lower TRL technologies and integrating them into a complex flight system, enabling the advancement of those 
technologies to TRL6. Morpheus’ low-cost, rapid prototyping SE approach greatly reduced the cost and time 
required for state-of-the-art propulsion and precision landing technology development relative to traditional NASA 
projects. Rapid, iterative prototyping fast-tracked requirements development, a major early SE investment for most 
projects, while simultaneously buying down risk for the final flight test vehicles. The project’s SE approach fostered 
high performance at a fast pace and low cost with the acceptance of higher risk to test hardware (a “fail forward” 
philosophy), as well as the almost exclusive use of existing JSC/EA online collaboration and tracking tools 
(eliminating training and paperwork) by a relatively small, highly focused and empowered engineering team in a flat 
organizational structure. The SE approach emphasized very frequent in-person and online collaboration amongst all 
subsystem teams to solve and avoid integration issues in real time, further enabling the fast pace of development and 
flight testing while precluding the added costs of rework or vehicle modifications. NASA Administrator Charlie 
Bolden held up Morpheus and its SE approach as a model for the agency in his 2013 memorandum, “NASA and the 
Importance of Risk”. 

Budget: 

Conducted all DDT&E and executed all flight test activities over span of 4 years with total procurement 
budget of $14M (including materials and all WYE) and an average of -40 FTE. 

Produced: 

3 integrated Morpheus flight vehicles, 

4 LOX/LCH4 engines of different design iterations (each advancing performance and thrust capacity), 

Multiple LOX/LCH4 RCS thrusters 
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Subsystem components for all vehicles plus spares (including avionics, GNC hardware, power, wiring, 
structure, RCS and main propulsion) - all designed and built in-house except minor components/connectors, etc. 

>80,000 SLOCs of software built on GSFC’s Core Flight Software platform and certified to CMMI level 3 
All ground support equipment for vehicle transport, fueling, test operations and vehicle comm 
Fully functional - and portable - operations control room with command and telemetry capability, self - 
designed data displays, recording functions, and an integrated capability to conduct flight training simulations with 
graphic depictions mimicking range safety and ops views and failure injection options 

A high-fidelity simulation capability that allowed for accurate projections of flight performance and post- 
flight analysis of system and sub-system behaviors 

Partnered with multiple centers to leverage capabilities that advanced Project goals with efficient 
investments, including flight testing at the KSC SLF and engine testing at Stennis E3 complex 

Multi-center integration facilitated through implementation of the SE methodologies outlined in section 8 
Reduced cost by operating with small SE staff 

Collaborative team environment reduced the need for dedicated personnel to provide “book management” 
function for requirements and other engineering database products 

Required subsystem leads to serve as system integrators and manage interfaces with other subsystems 
Use of “Home Depot” engineering exemplified by use of ultra-low cost prototypes to demonstrate 
fundamental behavior or design 

Morpheus slosh testing provides a good example. Two thirds of the mass of a lunar lander is propellant, so 
propellant slosh is important to understand and manage. The first prototype the project built used existing propellant 
tanks that did not have slosh baffles. For the current VTB, 
however, the team wanted to include baffles for a flight 
vehicle configuration. Team engineers needed to understand 
and simulate slosh for a four tank configuration, and validate 
simulations with a full scale slosh characterization test on 
the vehicle. The team quickly built the small prototype shown with $60 worth of Home Depot hardware. Tests with 
this model provided data to anchor the computer simulation, evaluate competing techniques for performing the full 
scale test, and more importantly gave the engineers an intuitive feel for the slosh dynamics which led to an elegant 
design for Morpheus propellant tank baffles. 

Reduced project tool costs: Used existing JSC EA-provided SharePoint site instead of paying for multiple 
specialized tool licenses or tool support contracts 

Schedule: 

The project achieved 60 flight tests over a span of 37 months. The KSC flight test campaigns with the 
Bravo vehicle included two tether tests, two RCS hot fire tests, and twelve free flights over a six month time period. 

Project moved seamlessly from design cycles to component test to flight testing phases (and repeated the 
transitions after the crash of 1.5 A) by modifying processes as needed for effectiveness 
Rapid pace of project life cycle enabled by the SE approach: 

Rapid decision-making enabled by daily interaction of PM and SE&I management with the technical team 
High level of forward momentum by daily management of team tasks during critical periods of the project 
Pace set with intermediate milestones to force progress 

Use of collaborative environment provided the whole team with immediate access to the “authoritative 
source” of project information 

Flat organizational structure with less boards and panels meant less time vetting presentation material 
before bringing forward to management 

After the crash of the 1.5A vehicle in August 2012, the Bravo vehicle was ready to fly just 8 months later. 
This demonstrated the quality of relevant design documentation, which allowed Bravo to be nearly identical other 
than the -70 design upgrades that were incorporated. 

Flight-to-flight maintenance was scrupulously managed using a maintenance list in the collaborative 
environment which allowed a quick turnaround between flights 

Performance: 
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The project flight test approach 
provided the means to reduce risk incrementally, 
using static hot fires, tether testing, and free 
flight envelope expansion before stepping up to 
the maximum 245 m altitude by 800 m 
downrange flight trajectory. 

The systems engineering approach 
ensured that anomalies were tracked and 
resolved; open discrepancies were evaluated for 
risk acceptance prior to each flight. 

Vehicle mass was carefully tracked by 
the vehicle managers, and when mass growth became a significant concern, the SE team worked thoroughly to 
attack it from all angles, including an increase in engine performance, a modified flight 
trajectory that still met ALHAT requirements, and mass reductions. 

The 1.5B vehicle upgrades provided a more robust and reliable flight test 
platform than the previous vehicle, with the elimination of several single point failures 
and risk reduction across all subsystems 

Upon completion of the envelope expansion flight tests, the Bravo vehicle was 
established as a stable, reliable test platform with well-characterized and predictable 
performance for an ALHAT payload weighing 400 lbs. 

III. Technical Management 

In 2009 the Space Shuttle, ISS, and Constellation Programs employed the 
majority of the JSC civil servant workforce. Like most large NASA programs, these had 
very large teams (>10,000 members) spread widely among NASA Centers and the Prime 
and many sub-contractors, costs in the tens to hundreds of billions of dollars over the 
program life, and the high rigor associated with sending humans into space. 

When the Morpheus Project was initiated in June 2010, the JSC Engineering 
Directorate recognized that, without a governing large program, the Morpheus team 
would have the opportunity to explore options for project execution. In contrast to those 
larger human spaceflight projects, Morpheus would have a small in-house team (<50 
FTE) primarily co-located at JSC with no Prime contractor and only minimal engineering 
support contractors or partners, and would not need to design for crew safety. However, 
since Morpheus’ scope included a flying vehicle, ground systems, and mission 
operations, there would be enough parallels to the larger programs that the team could experiment with approaches 
for potential application at larger scales. Furthermore, the team would gain a breadth and depth of design, 
development, and testing experience over a relatively short period of time. 

The Morpheus Project was not required to comply with NASA Procedural Requirements (NPR) 7120.5, 
“NASA Space Flight Program and Project Management Handbook,” or NPR 7123.1, “System Engineering 
Procedural Requirements.” However, both documents were used as bases for defining streamlined systems 
engineering products and processes early and throughout the project. In order to hold the line on lean development, 
project management guidance to SE&I was simply that “all processes had to buy their way onto the project.” Any 
effort, tool or process that would consume team members’ time had to demonstrate value with a short and easy 
learning curve. 
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The project defined a “scale of rigor,” as illustrated in Figure 1, graphically showing that as projects 
progress from technology development to human spaceflight, they must increase the level of rigor in the form of 
configuration management, requirements development, safety reviews, and decision board hierarchy in order to 
achieve higher levels of repeatability, redundancy and discipline for crewed missions. A generation has passed since 
NASA built a piloted spacecraft; so many highly skilled engineers have spent their entire careers in the sustaining or 
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Figure 1 - Project Scale of Rigor 

operational phase of the Shuttle and ISS Programs. Working with aerospace startups such as Armadillo Aerospace (a 
Morpheus partner in 2010) enabled the project team to experience first-hand the left side of this “scale of rigor” and 
to make informed choices regarding the “right” rigor for Morpheus. There is no formula for determining the “right” 
level of any of these attributes of rigor; it depends upon the goals and expectations of the project. More than whether 
or not to have a specific process, it is crucial to have the right level of process at the right time. 

Though Morpheus vehicles are unmanned, the project has always held public and team safety as a top 
priority. Thus, the project employed the highest levels of rigor to ensure safe operations, including the handling of 
cryogenic fluids, pressurized systems, laser payloads, and safety in the event of a vehicle fire or crash. 

The Morpheus “management team” consisted of the project manager, deputy project manager, SE&I Lead, 
and Chief Engineer. The management team’s technical engagement in the project enabled them to limit the amount 
of standing meetings and formal documentation. When a PM or SE&I Lead is present for the majority of technical 
discussions, his or her insight and understanding allows faster decision making with less need for engineers to 
produce a “change package” prior to discussion. The SE&I team still captured change rationale and ensured that 
design documentation was updated accordingly, but technical engagement by the PM ensured that project decisions 
were well-informed and timely. 

Vehicle Managers (VM) were crucial to Morpheus SE&I. When Morpheus was working with Armadillo 
near Dallas in 2010, having a “person on the scene” as much as possible facilitated rapid integration and 
communication, and lightened the paperwork burden on Armadillo engineers who were new to NASA’s more 
stringent documentation expectations. The project continued this approach by requiring VM presence in the vehicle 
hangar during all development and testing activities. One to three VMs worked at desks next to vehicles in the 
hangar and took turns being the vehicle “gate keeper.” Nearly all vehicle work had to be arranged through a VM 
who determined when a requested task needed management insight or approval and coordinated with other team 
members for integrated activities. 

While a systems engineer may impose processes, procedures, controls, and paperwork, he/she or the Chief 
Engineer is responsible for the technical integrity of the end products as much as the processes. So, the systems or 
Chief Engineer must maintain deep and broad technical insight and oversight. Morpheus’ Chief Engineer, SE&I 
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Lead and Project Manager also served as the control room Test Conductor during flight tests, requiring sufficient 
depth of knowledge to manage all subsystems before, during and after vehicle flight operations. Likewise, Vehicle 
Managers served as pad crew leaders, managing all test day preparations for launch, and all post-test vehicle safing 
activities from the pad to the hangar. Morpheus’ highly successful experience highlights the value of a technically 
engaged project management and systems engineering team. 

Projects often employ standard SE tools and processes due to precedent (“the way we’ve always done it”) 
or as a “common denominator” approach to systems engineering, regardless of team size, composition, or capability. 
The Morpheus team enjoyed the opportunity and freedom to try different methods and get immediate feedback from 
engineers. Some propose that SE should be “tool agnostic,” that it doesn’t matter what tools are used as long as they 
serve the needs of the SE team. However, the Morpheus experience shows that tool and process appeal, ease of use, 
and recognized value are essential to team buy-in and compliance. 

When Morpheus was first initiated, the JSC Engineering Directorate had just implemented a Microsoft 
SharePoint site for project collaboration and document management. The Directorate provided site-level 
administrative support and the basic infrastructure; the rest was up to the project. The intent here is not to 
specifically advocate for the use of SharePoint, but to describe how this particular integrated collaboration 
environment was used to solve many problems encountered with other approaches, and how it became the backbone 
for most of the systems engineering and many of the project management functions. 

Morpheus relied heavily upon three key SharePoint features, familiar to most SharePoint users: 

“Shared Documents” folders as document repositories 

Web & wiki pages for team organization, communication, and meeting workspaces 

“Lists” as project databases 

Each Morpheus subsystem team managed their own “sub-site” as they saw fit. The GN&C subsystem team 
documented the GN&C design using SharePoint “wiki” pages, enabling convenient wiki implementation shortcuts. 
The main home and SE&I tabs contained most of the integrated content. The Morpheus team found the most benefit 
using SharePoint lists in place of other custom database tools due to the following features: 


Lists are “Excel”-like 

The data entry record can include descriptive information to tell the user exactly what to fill in 
No special programming skills are required for the team end users or site owners 
Accessible by the entire team 

Each list, and each item, can be controlled with individual permissions for reading and modification 
Team members can add information to the database collaboratively and simultaneously; there is no 
document that needs to be checked out and checked in 
Every item is assigned an “owner” 

“Authoritative source” - the team never needs to wonder whether the List is the latest version or not 
Version history for each item; any change is automatically tagged with who made it, and when 
Team members can subscribe to changes and receive automatic email updates instantly, daily, or less 
frequently 

Data can be cross-referenced between lists. For example the “Test Log” is linked to “Discrepancies” so that 
each flight test shows a record of discrepancies that occurred. Figure 2 shows an example of data relationships for 
SE&I products. In most projects, these products exist as separately maintained databases or documents. In 
SharePoint, items can easily be linked to each other so that data relationships can be viewed and maintained. 

Can be implemented with as much or as little process rigor as appropriate 
Views can be tailored to show only selected columns or filtered fields 

Easy to tailor and add or modify Lists and fields to suit the needs of the team, so you don’t have to guess 
everything you’ll need up front 

Most information is accessible in any browser on any platform, though some views and editing require 
Microsoft Internet Explorer (IE) in Windows 

SharePoint has a close integration with Microsoft Visio, which can provide block-diagram style interactive 
drawings for websites that are dynamically linked with SharePoint list items 
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Figure 2 - Relationships between SE&I products 


SharePoint site administration overhead has been fairly low for the Morpheus Project. The SE team quickly 
learned the basics of managing and updating lists, and one SharePoint specialist provided administrative support 
with just a small fraction of her time. Nearly all of the features used by the team were out-of-the-box, with no 
special programming or third party tools (other than some requirements for IE in Windows). With SharePoint, along 
with Microsoft Office and other standard software tools, providing the basis for collaborative engineering, the real 
effort for the SE team was determining the level and manor at which to employ processes, relying upon the previous 
descriptions of rigor, determine how to maximize the added value of each process. 


IV. System Design 

The requirements process started with the definition of Needs, Goals, and Objectives (NGOs). From these 
NGOs, around a dozen Level 1 requirements were developed. The customer, the JSC Engineering Directorate, 
approved the NGOs and Level 1 requirements in an informal System Requirements Review (SRR). In parallel, a 
draft concept of operations was created using the tried-and-true collaboration approach of sticky notes on flip chart 
paper spread out across a conference room table. A top systems engineer who had been developing Constellation 
Program requirements for the Altair lander vehicle brought a model-based SE approach to the Morpheus team for 
the development of Level 2 (system) requirements using the Cradle tool, which incorporated both the concept of 
operations (electronically) and the top level requirements. In four weeks, the Morpheus team had a solid set of Level 
2 requirements from which to proceed with the design. 

Initially, the SE&I team tried to mimic the Cradle block diagram-to-data item interface using MS Visio, 
which could be linked dynamically with SharePoint. The demonstration worked well, but few team members had 
access to Visio, so the implementation did not support team collaboration. After the initial draft of Level 2 
requirements, the team moved the requirements database into a SharePoint list. Although Cradle is a highly capable 
tool, it requires a steep learning curve, expensive licenses, and administrative support to customize or tailor the tool. 
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Some Level 2 requirements flowed down to Level 3 (subsystems), but for the most part, subsystem teams were 
expected to generate their own Level 3 and interface requirements. 

The project and the SE&I team intentionally avoided over-defining or over-constraining end products, 
allowing prototyping and testing to dictate much of the capability. The team spent very little time “wordsmithing” 
the requirements because the high frequency of collaboration by a small, focused team greatly reduced any chance 
for incorrect interpretation. No requirements were being handed off to a contractor for bidding or implementation. 
This is an important point, since much of the labor typically spent on refining requirements stems from fear (often 
well founded) that a contractor will not produce the results envisioned, whether due to unintentional 
misinterpretation or the desire to reduce costs by meeting the most extremely minimal interpretation of the 
requirement wording. Such fears fade when the organization producing the requirements also produces the end 
product. 

In addition to the Pro-E models, vehicle subsystems and components were accounted for in the Master 
Equipment List (MEL) in SharePoint. Initially the MEL was used in an Excel-like format to list each component and 
its expected mass properties, including a weight growth allowance typically set to between 10-30%. Component 
specification sheets, vendor data, and photos were attached to the data records for individual items. Later in the 
project life cycle, the MEL was modified to track the as-built Morpheus vehicle configuration by recording the as- 
measured vehicle weight, as well as a history of component serial numbers on the vehicle at any given time. The list, 
which can be exported to Excel, has about 45 data columns for each component and currently contains almost 1,100 
components and sub-components. It is easy to sort by fields, and to view with only a subset of columns, such as a 
tailored view to just view items that are currently installed on the vehicle. 

After developing basic design concepts in partnership with Armadillo, the Morpheus team took delivery of 
the “1.0” vehicle structure from Armadillo, then integrated much of the avionics, the wiring, the GN&C sensors, and 
the main engine with JSC-developed components. The design process for the Morpheus 1.0 vehicle included 
multiple Design and Analysis Cycles (DACs). SharePoint provided an easy means for team members to provide 
inputs electronically in a collaborative database for the equivalent of “Task Description Sheets” that had been used 
on Orion. Having the inputs in a common database allowed all subsystems to view and edit each other’s entries, and 
to easily sort or filter during team discussions. 

The project had four major design reviews: two for the initial 1.0 vehicle configuration, one for 1.5A, and 
after the 1.5A vehicle crash, a “design upgrade review” was held to evaluate changes that would provide additional 
robustness and reliability. During the design phase of the 1.5B vehicle, the original requirements list from the 1.5A 
vehicle were scrubbed and revised and interface requirements were added based on what the team had learned over 
the previous year of testing. Approximately 70 upgrades were approved as changes from the 1.5 A vehicle to the 
1.5B vehicle. 

For each design review, each subsystem team populated a pre-defmed template, and all materials were 
uploaded to a SharePoint meeting workspace. As the project sought to maintain an appropriate balance between 
investing resources creating new material and the need for technical documentation, the design reviews were 
“forcing functions” for capturing information that otherwise might not have been recorded. Team members were 
encouraged to invite peer reviewers, and the project extended invitations to experts within the Engineering 
Directorate. Review Item Discrepancies (RIDs) were captured in a SharePoint list. The design reviews each lasted 2- 
3 days. Appendix G of NPR 7123 describes the recommended best practices for entrance and success criteria for 
technical reviews, and these were used as checklists for the design review content. In addition to the design reviews, 
the project held technical integration meetings to work specific technical issues at an appropriate frequency. 


V. Product Realization 

Subsystem leads were responsible for component and subsystem development up to the point of vehicle 
integration. In general, each subsystem applied best practices meeting the expectations of their own engineering 
discipline or division. There were some exceptions for which the project accepted risk associated with lower factors 
of safety, reduced testing, or lower margin, consistent with the overall project risk posture. Subsystem leads were 
also responsible for identifying appropriate quality control measures. 

The SE approach for subsystem development was to serve as an interface between subsystems, to ensure 
that subsystems conducted testing prior to vehicle integration, and to allow subsystems to define how development 
and subsystem testing would be performed. The amount and scope of testing varied by subsystem, and SE&I worked 
with them to capture the testing approach and followed up to ensure each test was completed. The SE team defined 
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and maintained the “Assembly Databook”, a detailed vehicle integration plan for managing dependencies and the 
order of component integration, and updated it weekly in SharePoint. 

The team defined verification requirements for each Level 1 and Level 2 project requirement, including 
necessary test events or analyses. Verification credit was sometimes taken for integrated tests, if the hardware and 
software was of a high enough fidelity. The primary approach for verification credit was through the initial field 
tests: dry run, wet run (with loaded liquid oxygen and liquid methane), and hot fire testing, prior to tethered flight 
testing leading up to free flight testing. 

The verification test list was managed in 
SharePoint for the 1.5 A vehicle 
development. For 1.5B, the team used a 
combination of X-Mind maps and burn- 
down lists to track and manage the tests 
and tasks leading up to them. 

All integrated tests and flight 
tests were recorded in the SharePoint 
test log. Discrepancies are added to the 
Discrepancy List, and the two lists are 
linked together. A useful feature of both 
lists is that videos and photos can be 
added as test evidence or for later 
discrepancy resolution. 

Of all the SE products, the one 
that is most used and enforced is the 
discrepancy list. When tracking recurring discrepancies, thorough records of previous events and resolutions were 
invaluable. All open discrepancies had to be closed or waived by the project before proceeding to the next flight test, 
so discrepancies were reviewed at each Test Readiness Review (TRR). As flight testing progressed, issues ranged 
from minor discrepancies to major problems and test failures (such as the crash of 1.5 A vehicle). The SE&I team 
reviewed each discrepancy, and for some failures, the team developed fault trees to ensure a methodical approach to 
determining the cause. 

The flight test objectives and test campaigns for Morpheus 1.5B used the same approach as the 1.5A 
vehicle, including a set of test objectives and test campaign planning for hot fire testing, tether tests, and a series of 
“envelope expansion” free flight tests at KSC leading up to the full ALHAT HDP trajectory. 

Morpheus/ALHAT flight testing included hazardous operations with pressurized tanks, cryogenic fluids, 
loud noise, extreme heat, lift operations, and potentially blinding lasers. The team maintained a list of hazards in 
SharePoint, including an analysis and identification of controls for each hazard. An engineer from JSC’s Safety and 
Mission Assurance (S&MA) organization was embedded in the Morpheus team in order to be highly knowledgeable 
about the vehicle systems and test operations. 

Flight test procedures were managed initially in SharePoint and modified for each test. JSC’s Mission 
Operation Directorate (MOD) provided an electronic procedures tool, “WebPD eProcedures”, that dynamically 
tracked procedure completion for all operators in the control room — and even at the pad using wireless iPads — 
during the 1.5B test campaigns. Flight rules and launch commit criteria were maintained in a SharePoint list and 
reviewed during flight operations tagups as changes were proposed. 

An internal team Test Readiness Review (TRR) preceded each new flight test configuration. These internal 
TRRs were typically chaired by the project manager and hosted by SE&I. The TRR sign-off used a “formal 
approvals” list in SharePoint, in which each responsible party can go into SharePoint and change the status from 
“not signed” to “signed.” Because SharePoint keeps a record of all changes, each changed entry is automatically 
time stamped with the user’s name. 

A post-test data review followed two to three days after each flight test. A folder was created in SharePoint 
for each flight test, and the team uploaded post-processed data plots, as-run procedures, and any presentations or 
files to explain test results. The SE&I team also managed a SharePoint list of key test parameters to be able to easily 
compare flight-to-flight performance. 
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V. Conclusion 

The Morpheus Project has provided an opportunity for a mostly civil servant team to conduct end-to-end 
vehicle flight operations with a terrestrial vertical test bed, and to advance integrated technologies that will benefit 
human spaceflight. Each flight test opportunity provided valuable insights, even when test objectives were not fully 
met. The team thrives on a project culture that recognizes the value of testing, failing, and recovering quickly to 
move forward and test again. 

Many of the findings from Morpheus are already making their way back into other programs/projects: 

The demonstration of CFS reuse in a flight vehicle and enhancement of GNC capability within has led to 
significant expansion of CFS utilization across the Agency, with significant potential savings 

Navigation design solutions are being adapted and implemented within Orion and other projects 
Differential draining data is informing the Orion service module propulsion system design 
Demonstrated precision landing is expanding the design options for science and precursor missions 
FOX/FCH4 advancements have emboldened pursuits for in-space demonstration of capability as a 
necessary step towards Mars exploration 

The appropriate level of rigor in team processes and methodologies enabled the Morpheus Project to 
progress rapidly and successfully along the path to flight testing. The fast pace and small size of the Morpheus team 
necessitated innovative solutions for team collaboration and communication, as well as a project management 
culture that expected any process or “overhead” to buy its way into the project based upon merit. 

The Morpheus Project incorporated a streamlined Systems Engineering and Integration (SE&I) approach 
by creating and implementing a model for systems engineering that is based in an interwoven SharePoint site that all 
team members rely on and access on a regular basis. The SE&I organization is lean and relies on a distributed 
team, yet still maintains appropriate documentation and enables efficient and effective communication amongst all 
team members that has been largely realized and is a primary reason for the success the Morpheus Project has had to 
date. The team’s efforts provide a cutting edge implementation that is essentially “rewriting the book” on SE&I and 
continues to evolve aspects that could be scaled up for larger projects and programs. 
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